1. Field of the Invention
This invention pertains to the field of digital computers, and more specifically to apparatus/methods for repairing computer software products that are in the possession of a user, i.e. software products that are in the field and installed on a computer system.
The present invention relates generally to an apparatus/method that provides for the repair of software that is written for use with the UNIX operating system, and more specifically UNIX System V, and UNIX System V, release 4. While the invention will be described with reference to the UNIX System V operating system, in its broader aspects the invention is not to be limited thereto. UNIX System V software products are prepared in accordance with package formats that are defined by the Application Binary Interface (ABI) that is a supplement to the System V Interface Definition (SVID). Software products in this ABI format are called packages.
Incorporated herein by reference are the following UNIX System V documents; (1) System V Definition, AT&T, a five volume publication by Prentice Hall, and (2) System V Application Binary Interface, AT&T, a publication by Prentice Hall.
2. Description of Prior Art
Installed software products, also called packages, often need to be repaired after the products have been delivered to a user and are installed on a computer system. This repairing operation is accomplished using what is known in the art as a software patch, or more simply, a patch.
A software patch comprises a sparse software package that is designed to overwrite certain files that exist in an original software package. The primary reason for shipping a patch containing sparse packages to existing users of the software package is to save space on the delivery medium such as a floppy disk. In the alternative, it is possible to ship the entire original package wherein the new files are different, and then use the pkgadd utility to install only the different files.
A patch must not change the intended delivered behaviors of the package being repaired; i.e., a patch is not a mechanism for installing new features. This can be done by keeping track of the patch status of the software package by using a System V pkginfo file entry which augments the package VERSION such as PATCH=010456-03.
If the software system is complex, it is wise to establish a patch identification system that will assure that no two patches can replace the same file, for example in an attempt to correct two different aberrant behaviors. In some cases it may be desirable to back out an installed patch, for example when a user prefers the original software package with its "defect".
If installation of the patch is not adequate, subsequent removal of the patch from the installed software must restore the file system to it's original state. This restoration requirement is often not possible, and the present invention is directed to solving this problem.
As is well known by those of skill in the art to which the present invention pertains, the UNIX System V operating system offers program administrators clearly defined behaviors when using the known System V utilities pkgadd (package add) and pkgrm (package remove). As is well known, pkgadd operates to add a software product, or package, to a computer system, whereas pkgrm operates to remove an installed software package from a computer system.
FIG. 1 through FIG. 3 illustrate the format for UNIX System V software packages defined by the Application Binary Interface (ABI) and conventional operations for patching software in UNIX System V. The standard UNIX System V ABI format is shown in FIG. 1. Number 10 represents a package's directory that contains package files. The name of directory 10 must be the same as the package name; for example, a package named SUNWcsu is comprised of a directory 10 named SUNWcsu and its contents. Within directory 10 are pkginfo file 11 and pkgmap file 12, as well as whatever other files are necessary to make up the package. Pkginfo file 11 describes the package as a whole, including special environment variables and installation directives. Pkgmap file 12 resembles a packing list in that it describes each object that is to be installed, examples of objects being file, directory, named pipe, etc.
Reloc directory 13 of FIG. 1 is a directory that contains the files and directories to be installed relative to the base directory defined in pkginfo 11, that is, the relocatable objects. Root directory 14 is a directory that contains files and directories to be installed relative to the root directory of the UNIX file system, that is, the root objects. Install directory 15 is a directory that contains scripts (UNIX shell programs) 16 and other auxiliary files.
The well-known System V ABI of FIG. 1 allows any file within a package 10 to be assigned to a class. All files that are within a specified class may then be installed to a disk using a method that is defined by a "class action" script 16. A System V package may make use of several shell scripts 16 which perform specific tasks during installation of the package objects. All scripts 16 are Bourne shell scripts.
The only required objects in a package are that of pkgmap 12 and the pkginfo 11. Once the directory-format package in accordance with FIG. 1 is constructed, it can be combined with other packages into a single stream-format package. This stream-format package can then be processed by the System V pkgadd utility.
The following System V utilities are used to manipulate packages:
"pkgadd" is used to install a package onto a host;
"pkgask" is used to dry-run the first part of a package installation for replay to a non-interactive pkgadd utility;
"pkgtrans" operates to transfer a package from one location to another, and to optionally translate the package to or from stream-format;
"pkgrm" operates to remove a package from the file system;
"installf" incorporates a new package object into a package that is already installed on the file system;
"removef" removes a package object from an installed package;
"pkgchk" verifies the integrity of a package in either installed or package form;
"pkginfo" returns information about a package;
"pkgparam" returns specific attribute values of a package;
"pkgmk" creates a package from a prototype file and a set of source trees; and
"pkgproto" creates a prototype file for use by "pkgmk".
FIG. 2 is a showing of a representative prior art means for installing a software patch on a host file system, and creating archive list 113 of FIG. 2 during this patch installation process. In FIG. 2, operation block 118 operates to install the software patch. As is well known, a software patch can consist of one or more patch packages, and a package can consist of one or more objects.
The first operation 100 that was performed in this prior system was to use the patch's pkgmap to query the host file system for a match to all of the patch objects that are within the patch to be installed. As is apparent to those of skill in the art, not all objects within a patch correspond to those that are within the file system; i.e., the patch object may be a new object.
Thus, decision operation 112 sequentially operates on all patch objects to determine if a correspondence has been found, and if the answer is "yes", then operation 113 operates to add each such existing file system object to an archive list. In this case, the process continues on to decision operation 114 whereat it is determined if the last patch object has been operated upon by operations 100, 112.
In the event that decision operation 112 determines that correspondence does not exist for a given patch object; i.e., the patch object is a new object that is to be installed on the host file system, then operation 114 is enabled by the "no" output of decision operation 112.
When all patch objects have been acted upon, and thus a complete archive list 113 has been compiled, operation 115 is enabled to use this archive list and create a backup archive that consists of all file system objects that are to be modified or replaced by installation of the patch. This backup archive may be a cpio archive, and it is represented by block 117 in FIG. 2.
As the last operation of FIG. 2, operation 118 is enabled to use the System V utility pkgadd to install the patch on the file system.
FIG. 3 shows a prior art means that operates to install archive list 113 of FIG. 2 on the host file system when operation of FIG. 2 has been faulty; i.e., when the installed patch did not work as intended on the host file system. As is well known, patch developers/manufactures extensively test their patches before delivery. However, in some cases the software product will not operate properly after a patch is installed. For example, the patch may not work properly with other patches that have been previously installed on the software product.
In this case, operation 200 operates to remove from the host file system each patch object that has been modified or replaced.
It is important to note that operation 200 does not remove from the host file system patch objects that were newly installed on the host file system by installation of the patch as shown in FIG. 2. The System V utility pkgrm may be used to perform operation 200.
In operation 201, archive list 113 is used to write the backout archive onto the host file system, thus restoring the host file system to the state in which it existed prior to the install-patch operation that is shown in FIG. 2, with the notable exception that patch objects that were newly installed on the host file system are not removed by operation of operation 201. The present invention overcomes this significant deficiency in the prior art.
Once operation 201 is accomplished, operation 202 operates to resynchronize the database of the software product. The System V utility pkgchk can be used with the "-f" option (pkgchk-f) to accomplish operation 202.